System And Method For Intrusion Prevention In A Communications Network

ABSTRACT

A method and system for monitoring UDP communications and for preventing unauthorized UDP communications within a computer network. A method for managing access to a resource comprises assigning a unique user identifier to each authorized user, upon initiation of a UDP communication initialed by a specific authorized user for access to a specific resource, appending the unique user identifier of the specific authorized user to each UDP packet of the UDP communication, intercepting the plurality of UDP packets within the computer network, extracting the unique user identifier from each UDP packet to identify the specific authorized user associated with the respective UDP packet, and allowing each respective UDP packet to reach the specific resource as a function of the unique user identifier extracted from the respective UDP packet.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation and claims benefit under 35 U.S.C. §120 of U.S. patent application Ser. No. 10/065,775, filed Nov. 18, 2002,now U.S. Pat. No. 7,386,889, entitled “System and Method for IntrusionPrevention in a Communications Network,” by A. David Shay, thedisclosure of which is hereby incorporated herein in its entirety byreference.

BACKGROUND OF THE INVENTION

This invention relates generally to network security. More specifically,the invention relates to a system and method for providing trustedcommunications and preventing intrusions in computer communicationsnetworks from occurring.

In the current state of the art, the common approach to communicationsnetwork security is an attempt to identify occurrences of attackeractivity after the attacker is present. This requires infrastructureinspections of every packet flow and a state-full inspection at thepacket level. After performing all of this work most of these approachesonly provide alert messaging of active breaches, thousands of them.Other approaches in security utilize personal encrypted keys and keyauthentication. These approaches while providing an attempt at sessionlevel control carry additional concerns and limitations associated withQuality of Service (QOS) performance impacts along with the need to addadditional information to each packet; thus, by looking at the packet,intruders have a clear picture of how and where to modify new packets.In the present context QOS refers to the overall throughput andperformance of a network infrastructure. Most corporate securityapproaches also include anti-viral, signature verification and NetworkAddress Translation (NAT) implementations. NAT enables a local areanetwork to use one set of Internet Protocol (IP) addresses for internaltraffic and a second set of addresses for external traffic. Recentattempts have been made to apply flow-based logic to identify hackeractivity. However, like their predecessors, these new approaches stillrely on “alter intrusion” recognition. While is still just that,detection not prevention.

Network security is of paramount importance to network administratorstoday. Cyber attacks are becoming more frequent and more publicized.Concerted cyber attacks by terrorist organizations can wreak havoc onthe infrastructure that modern societies have come to depend upon. Thecommon methods of attack include network packet sniffing, InternetProtocol (IP) spoofing, password attacks, denial of service attacks andapplication layer attacks. All of these methods require gaining accessto the network and no comprehensive solution exists in the prior art toprevent all forms of network intrusion.

A current effort to provide secure private communications over theInternet is Internet Protocol Security (IPSec). This framework usesencryption technology to provide confidentiality, integrity andauthenticity between peer devices in a private communications network.The IPSec protocol is a set of security extensions to the TCP/IPprotocol that uses cryptographic techniques to protect the data in amessage packet. The main transformation types are authentication header(AH) transformation and encapsulating security payload (ESP)transformation. AH transformation provides for authentication of thesender of data. ESP transformation provides for authentication of thesender and encryption of data. Both types of transformations can be madein either transport or tunnel mode. Transformation in transport modemeans that the original packet IP header will be the IP header for thetransformed packet. Transformation in tunnel mode means that the packetis appended after a new IP header. Both AH and ESP transformations addan extra header to the message packet, i.e., an AH header or an ESPheader. Separate key protocols can be selected including the Internetkey Exchange (IKE). Session keys have to be exchanged betweencommunicating peers in order to provide secure communications. AlthoughIPSec does address certain aspects of network security, it is not apanacea for all types of attacks. The use of an AH transformation doesnot protect the confidentiality of data; the use of an ESPtransformation protects the confidentiality of data, but also requireskey exchange, the use of additional headers increasing packet overhead,and the encryption of the actual data payload.

There is a critical need for an improved method and system for providingnetwork security that actually prevents intrusions into the network andprovides trusted communications between devices in the network.

SUMMARY OF THE INVENTION

The present invention provides an access control and user session layersecurity framework. It prevents unwanted connections to new and existingcomputing resources. It prevents unknown devices and/or users fromestablishing communication connections to the infrastructure. Itprevents unknown devices and/or users from establishing sessions toshared application resources. It prevents known users from gainingaccess to application resources that are not required in the executionof their area of responsibility.

Unlike traditional intrusion detection systems, the present inventionprevents intrusions rather than simply alerting a network administratorthat an intrusion is occurring. The technique used by this invention isthe first security approach that links business process to enabledtechnology utilization; thereby preventing anomalies in access andsession establishment. It utilizes authentication through real-timeprotocol manipulation.

The invention requires granted authentication at the hardware and usersession levels; thus linking hardware access to user requested services.By securing granted permissions at these levels, strange or unknownhardware devices are prevented from communicating with the networkinfrastructure; thus preventing threats associated with “walk-in”intrusions. Additionally, application resources are secured bycontrolling where user sessions are allowed; thus preventing “insiders”from gaining access to non-permitted resources and data.

The invention prevents the initiation of communication establishmentthrough extended manipulation of the communication protocol. Thisapproach places the decision point to the forefront of connectionestablishment rather than current methods of detecting unwanted “active”utilization or flow. It also eliminates the requirement for “state-full”inspection of every packet associated with end-to-end flows ofutilization; thus lowering the performance burden normally associatedwith intrusion detection.

The two major components of the invention are a “key master” softwarecomponent that is added to individual user workstations and networkresources, and a “gate keeper” component that can be added to existingfirewall devices or operate as a stand alone appliance within a trustedvirtual network. The key master software constructs a “transformed”packet header for a synchronization packet before transmitting thepacket to a destination node. The gate keeper component is an in-lineappliance or software module that intercepts all packet flows associatedwith a protected trusted virtual network. It processes the initialsynchronization packet received from a transmitting node and releasesevery other packet without further delay. The synchronization packetsare inspected to ensure that known hardware and known users arerequesting services for network resources that they can access. Thisinspection is performed by examination of the transformed packet headerin the received synchronization packet. Information contained in thesynchronization packet is compared to access policy profiles stored in arelational database management system at a network portal. Decisions topermit or reject the request for access to network services are madebased on these comparisons. At the receiving end of a connectionrequest, key master software in the receiving node initially identifiespacket type and evaluates a packet header field to determine whether tocontinue processing the packet. Authorization and verification areperformed by extracting and transforming data in packet header fieldsand passing the data to upper protocol layer stack processes. The keymaster software in the destination node toggles into a conversation modethroughout the rest of the connection until both the originating anddestination nodes are informed of the connection's termination.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is better understood by reading the following detaileddescription of an exemplary embodiment in conjunction with theaccompanying drawings, wherein:

FIG. 1 illustrates a system architecture for implementation of thepresent invention in accordance with an exemplary embodiment.

FIG. 2A illustrates the fields and overall format of a TCP packet.

FIG. 2B illustrates the fields and format of a UDP packet.

FIG. 3 illustrates a high level view of the major functions in theprocess flow for the key master and gate keeper intercept software inaccordance with an exemplary embodiment of the present invention.

FIG. 4 illustrates the processing logic associated with requestingnetwork connection services in accordance with an exemplary embodimentof the present invention.

FIG. 5 illustrates the processing logic associated with the gate keeperauthentication process to prevent intrusion in a communications networkin accordance with an exemplary embodiment of the present invention.

FIG. 6 illustrates the processing logic associated with the “performexception” process in accordance with an exemplary embodiment of thepresent invention.

FIG. 7 illustrates the processing logic associated with call setup andresponse at a destination in accordance with an exemplary embodiment ofthe present invention.

FIG. 8 illustrates the processing logic associated with packet flowafter a connection is established between two nodes in accordance withan exemplary embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

The following detailed description of the present invention is providedas an enabling teaching of the invention in its best, currently knownembodiment. Those skilled in the relevant art will recognize that manychanges can be made to the embodiment described, while still obtainingthe beneficial results of the present invention. It will also beapparent that some of the desired benefits of the present invention canbe obtained by selecting some of the features of the present inventionwithout using other features. Accordingly, those who work in the artwill recognize that many modifications and adaptations to the presentinvention are possible and may even be desirable in certaincircumstances, and are a part of the present invention. Thus, thefollowing description is provided as illustrative of the principles ofthe present invention and not in limitation thereof, since the scope ofthe present invention is defined by the claims.

The objective of the invention is to prevent intrusion before it occursby identifying intruders when they try to establish a connection. Thisnew approach not only delivers a pre-emptive methodology addressingoutside intruders but addresses internal intruders as well. Outsideintruders are defined as devices originating from the “outside” oroff-net who are attempting to connect to resources located within theenterprise infrastructure. Internal intruders are devices connectedwithin the infrastructure that are attempting to connect to unauthorizedinternal resources.

Unlike other solutions available today, the invention correlates eachrequest for service with the individual making the request and appliesavailability rules to the users' identification without tagging ormodifying packets. The invention utilizes the normal features ofprotocol operation and exploits how the protocol works to provideauthenticated user level security. This approach delivers a securemethod of communications without demanding abnormal construction ofpacket level data.

The prevention of unwanted communication is best served by simply notallowing the communication to begin. As an example, when a localtelephone company wants to prevent unwanted telephone usage, they simplyremove the dial tone. Without receiving a dial tone, a communicationcircuit cannot be opened. Much like the telephone, computers rely on theclosure of a virtual circuit to a destination address or device. Byapplying intelligent decision making capability at the point of arequest, unwanted or unallowable connection closure can be terminatedbefore it begins.

Resource and delay requirements for this approach will be lower than thetraditional approaches as the requirement for continuous state-fullinspection of all flow related packets is eliminated. By applyingintelligent decision capability at the beginning of a request forconnection, only the first few packets must be inspected.

The hand-shaking functions of all connection-oriented protocols duringinitial call setup provide enough information about the request forservice to make the decision whether to acknowledge and allow theconnection to be made or to terminate and drop the request. In addition,after a connection is established information held within the first fewpackets can also be inspected to determine the nature of an acknowledgedconnection request and to recognize the nature of the user's intent. Asan example, denial of service attacks can be identified by evaluatingthe interaction of the first five packets of the bi-directional flowbetween two nodes. Once the system of the present invention hasrecognized that initial interaction as damaging, it can automaticallyterminate the connection.

Signature or anti-virus enabled methods of countering virus-basedtransmissions can be fully supported by including anti-virus enabledsoftware within-the system of the invention. This additional featurewould be available through direct partnership with anti-virus softwarevendors such as Network Associates (McAfee security products) or NortonUtilities.

The following connection scenarios are addressed by the presentinvention:

-   -   1. Intercept software-enabled devices connecting to other        intercept software-enabled devices.    -   2. Intercept software-enabled devices connecting to        non-intercept software-enabled devices.    -   3. Non-intercept software-enabled devices connecting to        intercept software-enabled devices.    -   4. Non-intercept software enabled devices connecting to other        non-intercept enabled devices.

Scenario 1 can be described as an internal device connecting to acorporate application host. The origination node requests a connectionwith an application host that is within the trusted corporateenterprise. The request for connection is routed through the enterpriseand is evaluated by the corporate firewall already protecting the datacenter, if a firewall is present. An intercept software program looks atthe connection request and ensures that the device making the request isa known node and the authenticated user has permission to utilize therequested application. Once it has been cleared, the request continueson its way to the host destination. The host destination then respondsback to the origination node. Within this response are key indicatorsthat inform the node's intercept software that it has indeed connectedto an intercept software-enabled or approved device; thus allowing thecontinuation of the conversation.

Scenario 2 can be described as an intercept software-enabled deviceconnecting to a non-intercept software-enabled host. This scenario isapplied equally to both internally located hosts and remote hosts. Ineither case, a “gate keeper” software program evaluates compliance. Theoriginating node request is evaluated by the gate keeper softwareprogram implemented as an appliance or running within the firewall, thusensuring permissions to connect to the selected host are given. Theresponse does not contain the key indicators provided by an interceptsoftware-enabled device. The intercept software running in theworkstation recognizes that it has connected to non-interceptsoftware-enabled device and still continues the conversation. Becauseeach original request for connection is first evaluated by the gatekeeper software implemented as an appliance or running within protectedfirewalls, only permitted requests can complete their connections.

Scenario 3 describes a non-intercept software-enabled device attemptingto connect to an intercept software-enabled device. This scenario alsoaddresses both internal and external devices. Internal devices areconsidered first. As with-all other internal originating requests, thegate keeper software implemented as an appliance or running within thefirewall evaluates the request from the internal device. It willrecognize that the requesting device is not a known interceptsoftware-enabled device; by applying an exception policy to the request,gate keeper software will determine if the request is allowed. Ifallowed, gate keeper software will inform the receiving device that ithas been cleared and is allowed to respond. If the request fails theexception policy, gate keeper will drop the request thus terminating therequest. This approach prevents non-allowed connections from reachingthe protected host. If the requesting device is entering from outsidethe network (off net), the gate keeper software also processes theexception policy in the same manner. However, this scenario also caninclude an internal device that has been inserted into the enterpriseinappropriately, bypassing the gate keeper software or firewall. In thiscase, the originating device will reach the destination device (server)with a request. However, the intercept software-enabled server eitherterminates the request or responds back to the originating device withan inappropriate response. The connection will be terminated by the IPprotocol in its normal handling of broken connections.

Scenario 4 describes non-intercept software-enabled devices connectingwith other non-intercept software-enabled devices. By requiring allprotected internal enterprise devices to be intercept software-enabled,no unknown devices will pass the intercept software inspection withinthe gate keeper protecting a trusted virtual network. Corporations thathave the requirement for “outside” or global availability such as theworld wide web (HTTP) and Simple Mail Transfer Protocol (SMTP) serversto be used within their buildings can provide a dedicated domain orvirtual local area network (VLAN) that only has outside communicationabilities.

System Architecture

The system architecture of the intercept solution of the presentinvention includes the following components: portal, key mastersoftware, gate keeper software and an intercept management console. FIG.1 illustrates the system architecture of the present inventionpictorially. The figure depicts users 10, 12, 14, 16, 18 connected viaswitch 20 and router 30 to the enterprise network 40. The enterprisenetwork 40 can be a wide area network using the Transmission ControlProtocol/Internet Protocol (TCP/IP) for network communications betweendevices and users. Inside the enterprise network 40 are router 60,firewall server or gate keeper appliance 70, switch 80, servers 90, 92and mainframe 94. The intercept portal 50 and intercept managementconsole 54 are also shown and are further described below. The masterrelational database management system (RDBMS) and policy managersoftware are installed on intercept portal 50. Key master software isinstalled on protected server 90 and mainframe 94, as well as on enduser workstations 10, 12, 14, 16 and 18. The gate keeper software can beimplemented as an appliance protecting a selected trusted virtualnetwork (TVN) within the enterprise network.

The intercept portal 50 is a central point of initial key generation andregistration. Users 10, 12, 14, 16 and 18 authenticate to the portal 50and receive a unique software package (i.e., key master software) fortheir respective node. During the turn-up process users 10, 12, 14, 16and 18 authenticate with the portal 50 using the single login used fornetwork access as configured by the network administrator. The portal 50verifies this authentication with the primary domain controller (PDC)and either continues with the “key master” build or terminates theattempt. The PDC is a server in a Windows NT network that maintains aread-write directory of user accounts and security information. The PDCauthenticates usernames and passwords when members log into the network.Once the key master has been built, the portal 50 transfers and informsthe management console 54 of the addition. The intercept administratorwill then use the objective interface to drag and drop additionalpermission sets to the user's profile. Once the users' profiles areupdated, the users 10, 12, 14, 16 and 18 are ready to access allapproved resources.

Key master and gate keeper are software modules that could be simplyadded to existing firewalls 70 and end nodes, such as 10, 12, 14, 16 and18. Within the firewall or appliance 70, gate keeper software providesindividual session layer protection from unwanted access by controllingthe initial request for connection. Node key master software provides aunique identifier for each user 10, 12, 14, 16, 18 and device; thusallowing gate keeper full recognition of who is requesting service andwhat service is being requested.

The intercept software (key master and gate keeper) prevents the abilityto misuse resources by preventing unwanted users and non-allowedrequests to make connections. Rather than terminating an existing flow,the intercept software prevents the connection all together. Duringtimes where unwanted connections are continuously being requested,intercept software will re-direct the requests to an aggregation areawhere security personnel can “back-through” the connection and locatethe intruder. The intruder will not know that he is being tracked; thusavoidance measures will not be taken by the intruder.

Transformation/Reformation Processes

Two of the critical elements of the intercept framework are theprocesses of transformation and reformation. Transformation is theprocess of uniquely changing the values and alignment of hidden useridentifiers (UID) and system identifiers (SID) that describe who theuser is, what the user is attempting to use, the system being used andthe active session of the on-going connection. Reformation is theprocess of reversing the transformed identifiers yielding the true valueof each identifier. These “real” identifiers arc then used to enforceaccess and usability policies. The objective of transformation is toprovide a mechanism that prevents the transmission of usable identifiersacross an open network. By transforming identifiers used by theintercept software and the TCP/IP stack before they arc transmitted,potential intruders can only see what is on the wire, not what isactually being processed.

Transformation is accomplished by applying keys in a specific way thatchanges the original values of each identifier. These changes affect theoriginal value and the ordering of the bits. Transformation keys arerandomly selected from two key tables each containing 256 unique keys.The tables are referred to as the general key index (GKI) and thesession key index (SKI), respectively. Each key has an associated keyindex number that points to its value. Key indexes are randomly selectedby the key master software each time there is a new connection request.

The GKI table holds 256 keys that are used to change the value of anidentifier. As an example, consider a UID that has a “real” value of1234567890, a GKI key index number is randomly selected (157) and anassociated key that is extracted from the GKI table. Once transformedusing this key, the UID identifier's value is now changed (i.e.,transformed) to 5672348901. The GKI index number is then appended to thetransformed UID yielding 5672348901157.

A key index is then selected from the SKI table (e.g., 78). The SKItable holds 256 keys that are used to re-order the bits of eachidentifier throughout the life of the connection. Taking the aboveresulting number 5672348901157, the SKI key is applied transforming thenumber to 2319057547186. This resulting number is then used as thetransmitted initial sequence number (ISN) within the TCP/IPsynchronization (SYN) packet header.

As mentioned above, the intercept key master software also identifiesdie system being used (SID). Continuing with the above example, acomputed SID is 6789012345. The SKI index number used to re-order thetransformed UID number is appended yielding 678901234578. This number isthen re-ordered using a third key resulting in the final acknowledgement(ACK) number 307281584697 that is included in the SYN packet header.

When the gate keeper appliance (software) intercepts the SYN packet andparses its header information, the SYN and ACK numbers are extracted.Using the third key, the software reforms the ACK number yielding theSID and SKI. The SKI is extracted and used to reform the ISN yielding atransformed UID and GKI. The GKI is used to reform the UID yielding thereal UID.

Once the SYN packet has been received at its destination, the TCP/IPstack program begins parsing and processing the SYN packet normally.However, before it begins the process of verifying TCP header data, ituses the third key to reform the ACK number yielding the SID and SKI. Itstores the SKI and uses it to transform/reform all incoming and outgoingpackets for the duration of the connection.

Key Tables

As described above, there are two distinct key tables or arrays (GKI,SKI). Each table contains 256 128-bit keys and indexes (pointers) toeach. These tables are managed and updated in one of two ways.Initially, both tables are pre-populated with all 256 keys prior toimplementation in a communications network. Subsequently, the keys heldin these tables can be re-populated automatically with new key valuesthat are generated by a key generator. This automatic table feature canbe scheduled based on the network owner's requirement and performed bythe network's intercept software administrator.

As part of the intercept software interface and management consoleprogram, a selectable feature (“Key Table Maintenance”) option can beused by the administrator. This option schedules the tables for updatingand performs replication services needed to update gate keeperappliances and key master-enabled users.

The intercept system exploits the normal operational aspects ofcommunication protocols such as Transmission Control Protocol (TCP),User Datagram Protocol (UDP) and others. Brief descriptions ofconnection oriented and connectionless transport protocols are describedin the following sections.

Connection Oriented Protocols

Connection oriented protocols such as TCP/IP, Internetwork PacketExchange/Sequenced Packet Exchange (IPX/SPX) and others rely onhandshaking events to establish a connection. Connection establishmentbetween TCP hosts is performed by using a three-way handshake mechanism.A three-way handshake synchronizes both ends of a connection by allowingboth sides to agree upon initial sequence numbers. This mechanismguarantees that both sides are ready to transmit data and know that theother side is ready to transmit as well. This is necessary so thatpackets are not transmitted or re-transmitted during sessionestablishment or after session termination. Each host randomly chooses asequence number used to track bytes within a stream it is sending andreceiving. The first host (host A) initiates a connection by sending apacket with the initial sequence number (ISN) and SYN bit set toindicate a connection request. The second host (host B) receives theSYN, records the sequence number, and replies by acknowledging the SYN(within ACK=ISN.sub.A+1). The second host includes its own initialsequence number (ISN.sub.B). An ACK-20 means that the host has receivedbytes 0 19 and expects byte 20 next. This technique is called forwardacknowledgement. The first host then acknowledges all bytes the secondhost has sent with a forwarded acknowledgement indicating that the nextbyte the first host expects to receive is ACK=ISN.sub.B+1. Data transfercan then begin. By investigating information about the requesting user,the intercept system can ensure that each requestor is calling for anallowable connection before the connection is completed. Additionally,the intercept system can identify the intent of the requestor and ensurethat he is asking for a “normal” or “acceptable” service.

The fields and overall format of a TCP packet are shown in FIG. 2A. Thesource port and destination port fields identify points at which upperlayer source and destination processes receive TCP services. Thesequence number field usually specifies the number assigned to the firstbyte of data in the current message. In the connection-establishmentphase, this field is also used to identify an initial sequence number tobe used in an upcoming transmission. The acknowledgement number fieldcontains the sequence number of the next byte of data that the sender ofthe packet expects to receive. The data offset field indicates thenumber of 32-bit words in the TCP header. The flags field carries avariety of control information, including the SYN and ACK bits used forconnection establishment, and the FIN bit used for connectiontermination. The window field specifies the size of the sender's receivewindow. This represents the buffer space available for incoming data.The checksum field indicates whether the header was damaged in transit.

Connectionless Protocols

UDP, multicast and other protocols do not utilize a handshake method ofestablishing a connection. UDP is a connectionless transport-layerprotocol that belongs to the Internet Protocol family. UDP is basicallyan interface between IP and upper layer processes. UDP protocol portsdistinguish multiple applications running on a single device from oneanother. UDP is useful in situations where the reliability mechanisms ofTCP are not necessary, such as in cases were a higher-layer protocolmight provide error and flow control. UDP is the transport protocol forseveral well-known application layer protocols, including Network FileSystem (NFS), Simple Network Management Protocol (SNMP), and Domain NameSystem (DNS). The UDP packet format contains four fields as shown inFIG. 2B. These include source and destination ports, length, andchecksum fields. Broadcast type flows operate in a uni-directionalfashion; thus the intercept system locates unique identifiersdifferently than those using a connection-oriented protocol but willstill prevent unwanted flows by pooling the broadcast stream andverifying the initial packet of the stream.

There are two levels of device authentication and identificationproviding hardware and user session security. First, information aboutthe specific device is maintained in the key master software. Thisinformation maintains a description of the hardware and is verified eachtime the device is used. By placing this information within the keymaster software, the software itself cannot be copied and placed onother devices. Without successful authentication, no networkconnectivity will be permitted. Secondly, unique identifiers are createdeach time the device is used by a user. This information is uniquelytransformed and becomes part of the normal packet structure. All uniqueidentifiers and other unique data points are computed together formingthe initial sequence number (ISN) of the request. Communicating hostsexchange ISNs during connection initialization. Each host sets twocounters: sequence and acknowledgement. Held within the ISN are uniquekeys that identify the user and are used to grant authorization. Byutilizing normal protocol operands to carry authenticated identifiers,no modification to the packet structure is required; thus, intruderswill notice no differences between a non-intercept software-enabledpacket and an intercept software-enabled packet. Only by having acomplete knowledge of how the intercept software operates, theidentification of all data points used in the ISN computation and exactformulas used could a probable breach be successful.

This initial packet along with the unique identifiers are routed to itsdestination as usual; however on its way to the destination the packetis picked up by the gate keeper enabled appliance or firewall. The gatekeeper software intercepts synchronize (SYN) packets specifically andperforms reverse algorithms to the ISN, correlates encrypted identifiersto fully qualified user name (FQUN). Application and destinationidentifiers are also identified. It then applies availability rules tothem and either forwards the SYN to its destination or rejects and dropsthe request. The SYN flag is only set when establishing a TCPconnection.

The two major components of the intercept system software are theintercept software-enabled firewall or appliance (gate keeper) and theintercept software-enabled node (key master).

The key master module is a software component that can be added to userworkstations 10, 12, 14, 16, 18 and network resources such as server 90,mainframe 94 with reference to FIG. 1. The gate keeper module is asoftware component that can be added to existing firewall devices oroperate as a stand-alone appliance 70 as depicted in FIG. 1. As asoftware solution, investments and positioning of existing firewalls canbe leveraged.

FIG. 3 illustrates a high level view of the major functions of the keymaster and gate keeper intercept software. Process blocks 200 and 210indicate functions performed by the key master software at theoriginating node of a network connection. Process blocks 220, 230 and240 indicate functions performed by the gate keeper software onintercepted packets intended for a network destination. Process blocks250, 260 and 270 represent functions of the key master softwareperformed at the receiving end (destination node) of a networkconnection. As indicated in process block 200, the originating station(source node) requests network services. Key master software is loadedand running in all enabled nodes, work stations, servers andintermediate devices. The key master software is responsible for thefirst level of authorization and construction of intercept-enabledpackets. Leveraging the mechanics of the protocol, the key mastersoftware provides a method of identification and verification of boththe hardware and the user. This is indicated in process block 210, whichrepresents the functions of authenticating the system identification(SID), constructing and sending a SYN packet, using a session GKI/SKI.

The gate keeper in one embodiment is an in-line appliance thatintercepts all packet flows associated with a protected trusted virtualnetwork (TVN). Each packet that is routed in or out of a TVN isinspected in real time. Only the initial SYN packet is processed; allothers are released without further delay. In process block 230, theGKI/SKI is extracted; the ACK and ISN are authenticated; and policyauthorization is checked. SYN packets are investigated to ensure thatknown hardware and known users are requesting services from systems andapplications that they are allowed to use. Using information held in theintercept SYN packet, profiles are compared to the requests. By lookingup these individual profiles, decisions can be made to allow or disallowthe connection request. The packet is released or dropped as indicatedin process block 240.

At the receiving end of a connection, the receiving node accepts the SYNpacket to begin the intercept receive process. This is indicated inprocess block 250 with the SYN reaching its destination node. Afteridentification of a packet type (SYN), the ACK field is evaluated and adecision is made to further process the packet. As indicated in processblock 260, the SKI is extracted and used to construct the SYN/ACK.Authorization and verification is performed by extracting andtransforming the ISN and ACK data and passing it to upper layer stackprocesses. The destination node sends a SYN/ACK to the originating nodein process block 270. The key master software toggles into conversationmode throughout the rest of the connection until the FIN/ACK processinforms both the originating node and the destination node of theconversation termination.

Once the SYN is received by an intercept system protected host, the hostresponds back in its usual manner. However, the protocol operands areonce again modified. This modification is directed to how thedestination device acknowledges the ISN. Rather than the standard ISN+1,the intercept system utilizes an intercept-enabled transformationalgorithm and modifies the sequencing of the flow. If the connectionrequest has originated from a non-intercept system enabled device, thenormal rules of protocol handshaking will terminate the connection thuspreventing the intrusion.

The gate keeper software includes the following components:

-   -   Packet grabber    -   Protocol factory    -   Transformer    -   Event broker    -   Re-director    -   Date store    -   Message broker

The packet grabber is responsible for selecting only the SYN packets ofany given connection request. The packet grabber identifies SYN packetsand send them to the protocol factory for further processing. Only SYNpackets are grabbed.

The protocol factory is responsible for identifying the protocol andcalling the proper parser for packet parsing functions.

The packet parser selects specific header and frame information aboutthe SYN packet. It then performs look up functions to verify permissionsand key identification by calling the transformer. The packet parsermakes the decision to allow the connection, terminate the connectionrequest or re-direct the request to the intercept system console. Ituses the data store as a decision support tool.

The transformer reverse computes the transformed identifiers whichcontains unique key data. This key data identifies the user making therequest. Rules are applied to this data so the packet parser can make ago/no-go decision.

The event broker executes the actions as directed by the packet parser,either allowing the connection, dropping the connection request orrequesting re-direction. The event broker also logs requests and theiractions.

The re-director takes data from the event broker and directs it tomultiple places as defined. The data store is used to maintain keyidentifiers and permissions. It is automatically updated through themessage broker.

The message broker provides synchronized replication of changed data soevery known intercept software-enabled appliance or firewall has currentup-to-date policy data.

Key master software is device driver software only. It modifies themethodology controlling the creation and interpretation of unique SYNsequence numbers and acknowledgement (ACK) numbers. Using both thedigital key and fixed formulas, it generates a unique 32-bit sequencenumber and ACK number. Held within the sequence number are identifiersfor the active session and user ID. Held within the acknowledgementnumber are identifiers for the hardware and transformation keys.Although intercept software creates unique numbers they adhere to allInternet Engineering Task Force (IETF) Request for Comments (RFC)standards regarding protocol use of those numbers. As such, nomodifications are needed to normal infrastructure operations and packetdelivery.

In order to “turn-up” a new intercept system-enabled user, the userneeds to be added to the intercept system data store and have a uniquekey master (SID) created. The key master software utilizes the originalmedia access control hardware (MAC) address embedded as part of the SIDand determines if the requesting workstation's present MAC address isthe same as the registered address. The SID is created by taking the MACaddress of the user's workstation plus the actual time stamp of theaddition (measured in milliseconds).

This comparison prevents unknown devices from being connected at trustedlocations such as a wiring closest. Additionally, it prevents illicitcopies of the key master SID from being installed on unwanted systems.If the MAC address comparison fails, key master software informs theadministrator and disallows connectivity.

When the user's workstation is enabled, he can use an applicationresource. When the user generates a request for connection, the keymaster software creates a unique SYN/ISN containing a 24-bit CRC of theUID that has been transformed plus a randomly selected GKI. The UID is afully qualified user name FQUN plus the domain name. This is computed bytaking the user ID name (e.g., dshay) and the authenticated domain nameand computing a 24-bit numerical value. The CRC is computed by takingthe UID and computing a normal cyclic redundancy check (CRC).

These numbers are then combined and computed using a transformationalgorithm to create the unique SYN/ISN. Additionally, key mastersoftware computes a unique SID by taking the MAC address of the activenetwork interface card and the stored time stamp and creating a 24-bitCRC numerical value. A randomly selected SKI is then combined to this24-bit number and the resulting 32-bit number is transformed to createthe ACK number. Because the uniquely generated sequence number and ACKnumbers are 32 bits in length, they don't alter any requirementsspecified by the RFCs governing the TCP/IP protocol.

The complete SYN packet is then normally routed through the network,heading towards its destination. Before it reaches its destinationaddress; however, the packet is picked up by the gate keeper software.It begins by evaluating the ACK number. If the ACK number contains azero value the request is recognized as an untrusted request and isprocessed by the exception policy. The exception policy is applied toverify a pre-existing policy for untrusted requesting sources. If theexception request is granted gale keeper assigns a unique identifiableACK number that is understood by enabled receiving devices; if noexception policy exists the request is dropped. If the request is notidentified as an exception (a non-zero ACK number), it is processed asan enabled request. As a normal enabled SYN packet, gate keeper reformsthe received ACK number yielding the SID and SKI. The SKI is then usedto reform the ISN yielding a transformed UID and the GKI. The GKI isthen used to reform the UID yielding a real UID. Continuing the process,gate keeper then verifies the UID and selects the level of policy toapply, if no other policy is defined for the UID, the packet isreleased. However, if additional levels of policy arc defined, gatekeeper verifies each policy component. These policy components caninclude authorization of the hardware device by verifying the SID,application authorization by verifying the destination port identifieror any combination including all components.

From the combination of this information, the following is known:

-   -   intercept system-enabled request packet coming from a known        device;    -   the identification of the user that is making the request for        connection; and    -   where the user wants to go (destination) and what the user wants        to do (resources).

A set of permissions (i.e., policy) can now be evaluated for eachindividual user. If user “dshay” is authenticated to his normal domain,the intercept system will be able to recognize the user within the datastore and allow him to work within his restrictions. If the user (dshay)needs to use someone else's workstation, he will still need to find anintercept system-enabled node. In addition, the user will still have toauthenticate to his normal domain and be recognized by either thePrimary Data Controller (PDC) or the intercept system. As discussedabove, the PDC authenticates user names and passwords when members loginto the network. Members only have to log into one domain to access allresources in the network.

FIG. 4 illustrates the processing logic implemented in the key mastersoftware to control requests from end users for network connectionservices. Processing starts in logic block 400 with the user performinga TCP/IP Open call requesting a connection to a network service. From anoperating system perspective, end user workstations requesting a serviceask the TCP services program to open a new connection request whichstarts the functions needed to build a request packet (SYN) and toprepare the packet for transmission.

The TCP protocol requires the establishment of a controlled connectionbetween two devices before data can be exchanged. This connectionprocess requires the requesting device to send an Initial SequenceNumber (ISN) so that the connection can have a starting point shared byboth devices. As noted previously, the ISN is a 32-bit integer that israndomly generated by the stack. The key master software takes Controlof the method by which this number is generated and creates an ISN thatholds a previously computed UID. The UID is then used to identify theindividual user making the request before the request packet is receivedat its destination. By using the FQUN computed earlier, a 24-bit CRCvalue is computed and stored in a session oriented temporary variable.

Before the connection request begins, the key master software obtainsthe identification of the requesting machine (SID) and the user accountidentification (UID). By grabbing the Media Access Control (MAC) addressof the network interface card (NIC) along with the original time stamppreviously stored, a 24-bit transformed SID is created. This processingstep is indicated by logic block 404. Located in the key mastersoftware, this function call is executed before the Open call, thereforeit controls the go/no go state. By intercepting the connection request,authorization decisions can be made before an intruder has connected tothe network.

In decision block 406, a determination is made as to whether the machine(i.e., workstation) requesting connection is the same machine usedduring turn-up. By comparing the computed SID, the key master softwarecan determine if the machine is the same machine used during turn-up. Ifthe key master software has been copied to another machine, or theaccess request is bound to a known network interface card (NIC), thesession values will not match the stored values and the request will beterminated. If the authentication check fails in decision block 406, thekey master software will inform the security administrator of the failedattempt to connect as indicated in logic block 408. This message isreported and stored in the event database within the portal RDBMS. Thisinformation is used to identify and track unauthorized events.

The key master software includes two arrays of transformation keys.First a GKI used to transform the UID and second the SKI used totransform outgoing packets. Each array has index pointers that areassociated with a key's value. After the UID has been computed, a GKIindex and an SKI are selected for the transformation steps. Thisprocessing step is indicated in logic block 410. The previously computedUID is transformed by the GKI as indicated in logic block 412.

As indicated in logic block 414, the GKI is then added to the resultingtransformed UID. The previously selected SKI is then used to transformthe resulting transformed UID plus GKI as indicated in logic block 416.The resulting number is then used as the ISN and is stored in the socketbuffer and is ready for transmission (logic block 418). The previouslyselected SKI is appended to the previously computed SID as indicated inlogic block 420. The resulting number is then transformed as indicatedin logic block 422. The transformed number is the IACK and is placed inthe socket buffer as indicated in logic block 424. The resulting SYNpacket is now ready for transmission and is delivered by the protocoltransport system, as indicated by logic block 426.

The processing logic associated with the authentication processperformed by the gate keeper software is illustrated in FIG. 5. As shownin FIG. 1, the gate keeper 70 is an in-line active device. It performsservices similar to a typical firewall. It receives all packets thatflow bi-directionally on network circuits, investigates each packet,selects only specific packets for further processing, and releases allother packets. The processing logic for the gate keeper software can bedelineated into a number of processing blocks that are shown in FIG. 5.These process blocks include promiscuous packet capture; protocolidentification and packet identification: parsing and fetching;transformation/reformation; authorization verification; connectionaction; and notification. When executing in promiscuous mode, everypacket transmitted on to a protected circuit is captured and placed inthe input buffer. Protocol identification is performed by evaluating theIP header data in the packet. Once the protocol type code is identifiedas TCP, the packet header is again evaluated for an active SYN flag. Ifthe packet is a SYN packet, it is then further processed. If it is notan SYN packet, the packet is immediately released and sent on to itsdestination.

Processing commences in logic block 500 with the step of receiving apacket flow from a node. In step 502, the received packet is parsed. Indecision block 504, a test is made to determine if the packet is a TCPpacket. If it is, then in decision block 506, a test is made todetermine if the packet is an SYN packet. If it is not a SYN packet, thepacket is released as indicated in step 508. Once the packet has beendeclared a TCP packet with the SYN flag set, the ACK field is verified.In decision block 51.2, if the ACK field has a value greater than zero,then the ACK value and extracted SID/SKI are reformed as indicated inlogic block 516. If the ACK field has a value of zero, an exceptionroutine is then performed as indicated in logic block 514. Furtherdetails associated with the performance exception routine are depictedin FIG. 6. Following the reform process in logic block 516, the ISN isreformed. The reformed ISN reveals the transformed UID and the GKI asindicated in logic block 518. The GKI is then extracted as indicated inlogic block 520. Using the GKI, the transformed UID is reformed toreveal the user identification (UID) as indicated by logic block 522.The resulting UID is verified in logic block 524. If this is found to bea bad index number, the connection request is dropped. The resulting UIDis then searched for in the data store containing all known userprofiles. A test is made in decision block 526 to determine if the UIDhas been found. If the UID has been found, then it is passed on to thenext processing block, logic block 532 for further authentication. Ifthe resulting UID is not found (decision block 526), the connectionrequest is dropped (logic block 528) and a message is sent to theadministrator as indicated in block 530.

After the UID has been found (yes path out of decision block 526), theUID process policy is inspected in logic block 532. This inspectioninforms the gate keeper software of the level of policy in effect forthis user. The process flags the five levels of policy to apply to eachuser. These policies provide for the inspection of hardware (H),requested application (A), requested destination (D), and no policy atall (N). In decision block 534, a test is made to determine if there isa hardware or a requested application policy defined for the user. If ahardware policy is defined, the SID is then verified as indicated inlogic block 536. The SID identifies the source node making the request.A test is performed in decision block 538 to determine if the SID hasbeen found. If the SID has not been found, then the request is dropped(logic block 540) and a message is sent to the administrator asindicated in block 542. If the lest in decision block 538 passes, thepacket is released to the destination, as indicated in logic block 546.In decision block 534, if an application policy is defined, thedestination port is verified (logic block 548). In decision block 550, atest is made to determine if the user is authorized to access therequested application. If the user is so authorized, the packet isreleased to the destination as indicated in logic block 560. Otherwise,the request is dropped (logic block 528) and a message is sent to theadministrator as indicated in logic block 530. If neither a hardwarepolicy nor a requested application policy is defined for the user, atest is then made in decision block 544 to determine if there is eithera requested destination policy or no policy at all defined for the user.If a requested destination policy is defined, a destination port isverified in logic block 552. If a destination port is accessible to theuser, then the packet is released to the destination as indicated inlogic block 560. If in decision block 554, the destination port is notavailable to the user, the request is dropped (logic block 556) and amessage is sent to the administrator, as indicated in block 558.

FIG. 6 illustrates the processing logic associated with the “performingexception” process. When the value held in the ACK field is zero, thegatekeeper software knows that the packet has originated from anuntrusted source. The exception routine is executed because of therequirement to provide selected untrusted source access. The originationsource address is extracted from the IP layer in the verified sourceaddress logic block 600. The extracted source address is then verifiedfrom the exception table as indicated in decision block 602. If thistest fails, the connection request is dropped (logic block 604) and amessage is sent to the administrator in logic block 606. If theextracted source address is verified as a non-address in decision block602, the requested destination is then verified by extracting thedestination address in the IP layer. This is indicated in logic block608. The extracted destination address is then verified from theexception table in decision block 610. If the lest fails, the request isdropped in logic block 604. If the extracted destination address isverified in decision block 610, then the packet is further tested byextracting the destination port number from the TCP layer to verify theapplication request in logic block 612. The destination port number isthen verified in the exception table as indicated in decision block 614.If the test fails, the request is dropped in logic block 604. If thetest passes in decision block 614, the request is then ready fortransformation. This transformation occurs in logic block 616 with thegeneration of a unique initial ACK number (IACK). This unique numberwill be authenticated by the key master software at the destination nodeas a recognized gate keeper-induced number. An SKI is selected next, asindicated in logic block 618. The selected SKI is then added to the IACKin logic block 620. The resulting number is then transformed in logicblock 622 and stored as the ACK in logic block 624. The SYN packet isfinally reassembled and the CHECKSUM is recalculated in logic block 626.The SYN packet is then released as indicated in logic block 628.

FIG. 7 illustrates the processing logic associated with call set up andresponse from a destination node, after receiving the packet from gatekeeper appliance 70. Processing starts in decision block 700 with a testto determine if an incoming packet is an SYN packet. The incoming packetis inspected and tested for the SYN flag being set. If the SYN flag isset in the packet, set up processing is required. If the SYN flag is notset, the packet is not an SYN packet and the packet is deemed as beingassociated with an established connection and is processed differently(see FIG. 8). If the SYN flag is set, then a test is performed indecision block 702 to determine if the ACK field is equal to zero. Thistest protects against untrusted nodes establishing a connection. If theACK field is zero, the packet is dropped in logic block 704 and amessage sent to the administrator in block 706. If the ACK field isnon-zero, further connection set up processing is performed. The ACK isreformed utilizing the static routine in logic block 708. The SKI isextracted from the transformed ACK number as indicated in logic block710. The extracted SKI is then stored in a buffer variable (logic block712) and is used throughout the conversation. Next, as indicated inlogic block 714, the ISN is reformed using the SKI to reveal the realsequence number. The resulting real sequence number is stored in thebuffer as indicated in logic block 716. The ACK number is set to a zerovalue in logic block 718 with the zero value stored in the buffer inlogic block 720. The resulting stored numbers (SEQ+ACK) are processedusing normal stack processing, as indicated in logic block 722. Beforethe tcp-send 0 function is executed, the sequence and ACK numbers aretransformed using the stored SKI as indicated in logic block 724. Theresponse packet is then transmitted as indicated in logic block 726.

FIG. 8 illustrates the non-SYN packet processing flow that is executedafter a connection has been established. Using the SKI stored duringconnection set up, the sequence number is reformed to reveal the truesequence number as indicated in logic block 800. The resulting sequencenumber is then stored in the receive buffer as indicated in logic block802. Using the previously stored SKI, the ACK number is reformed toreveal the real ACK number in logic block 804. The resulting ACK numberis then stored in the receive buffer in logic block 806. The packet andits data then go through normal stack processing as indicated in logicblock 808. As the packet is processed by the stack and readied fortransmission, the sequence number is once again transformed using thestored SKI in logic block 810. The normally produced ACK number is alsotransformed using the stored SKI in logic block 812. The packet is thenplaced in the transmit buffer by the stack and transmitted to itsdestination in logic block 814.

The present invention can be realized in hardware, software, or acombination of hardware and software. Any kind of computer system orother apparatus adapted for carrying out the methods described herein issuited. A typical combination of hardware and software could be ageneral purpose computer system with a computer program that, when beingloaded and executed, controls the computer system such that it carriesout the methods described herein. The techniques of the presentinvention can also be embedded in a computer program product, whichcomprises part or all of the features enabling the implementation of themethods described herein, and which, when loaded in a computer system,is able to carry out these methods.

Computer program in the present context mean any expression, in anylanguage, code or notation, of a set of instructions intended to cause asystem having an information processing capability to perform aparticular function either directly or after either or both of thefollowing occur: a) conversion to another language, code or notation; b)reproduction in a different material form. Computer program alsoencompasses hard-wired instructions embedded in an electronic deviceincluding semiconductor chips or cards, network appliances, routers,switches, servers, firewalls and client devices such as networkcomputers, workstations, desktop computers, laptop computers andhandheld devices. Specifically, a number of functions performed at theprotocol or packet level can be embedded in Application SpecificIntegrated Circuits (ASICs). Such functions can include the parsing orrouting of packets. The invention can also be embedded in single boardcomputers (SBCs), with a Linux operating system and silicon-based datastorage. Multiple boards can be installed in slots in a chassis as“blades” (similar to router blades in a router chassis) thus providingmultiple gate keeper appliances.

The corresponding structures, materials, acts, and equivalents of anymean plus function elements in any claims are intended to include anystructure, material or acts for performing the function in combinationwith the other claimed elements as specifically claimed.

While the invention has been particularly shown and described withreference to a preferred embodiment thereof, it will be understood bythose skilled in the art that various other changes in form and detailmay be made without departing from the spirit and scope of theinvention.

1. A method for managing access to a resource within a computer network,comprising the steps of: assigning a unique user identifier to eachauthorized user of the computer network; upon initiation of a UDPcommunication initiated by a specific authorized user for access to aspecific resource within the computer network, appending the unique useridentifier of the specific authorized user to each UDP packet of the UDPcommunication; intercepting the plurality of UDP packets within thecomputer network; extracting the unique user identifier from each UDPpacket to identify the specific authorized user associated with therespective UDP packet; and allowing each respective UDP packet to reachthe specific resource as a function of the unique user identifierextracted from the respective UDP packet.
 2. The method of claim 1wherein the unique user identifier comprises a user name of the specificauthorized user.
 3. The method of claim 1, further comprising the stepof encrypting the unique user identifier prior to appending the uniqueuser identifier to each of the UDP packets.
 4. The method of claim 3,further comprising the step of decrypting the unique user identifierafter extracting the unique user identifier from each UDP packet.
 5. Themethod of claim 1, further comprising the step of notifying a networkadministrator if one or more of the UDP packets of the UDP communicationattempt is not allowed to reach the specific resource.
 6. The method ofclaim 1, further comprising the step of logging the respective UDPpacket if the UDP packet is not allowed to continue to the specificresource.
 7. The method of claim 1, wherein the specific resource is adatabase.
 8. The method of claim 1, wherein the specific resource is anapplication.
 9. The method of claim 1, wherein the specific resource isan authorized computer within the computer network.
 10. A method forpreventing unauthorized access to one or more resources within acomputer network, wherein the computer network includes a plurality ofauthorized users and wherein a unique user identifier is assigned toeach of the plurality of authorized users, comprising the steps of:maintaining the plurality of unique user identifiers in a database;intercepting a UDP packet from an undetermined user, wherein the UDPpacket represents a communication attempt with a specific resourcewithin the computer network; obtaining data from the UDP packet;comparing the data obtained from the UDP packet with the unique useridentifiers maintained in the database; and preventing the UDP packetfrom reaching the specific resource if the data obtained from the UDPpacket does not match one of the plurality of unique user identifiersmaintained in the database.
 11. The method of claim 10, wherein eachunique user identifier comprises a user name of the specific authorizeduser.
 12. The method of claim 10, further comprising the step ofdecrypting the data obtained from the UDP packet if the data has beenpreviously encrypted.
 13. The method of claim 10, further comprising thestep of storing the UDP packet in a database.
 14. The method of claim10, further comprising the step of notifying a network administrator ifany UDP packet is blocked.
 15. The method of claim 10, furthercomprising the step of storing the data obtained from the UDP packet ina database.
 16. A method for monitoring access to a specific resourcewithin a computer network, comprising the steps of: assigning a uniqueuser identifier (UID) to each authorized user of the computer network;assigning a unique, non-dynamic system identifier (SID) to eachauthorized computer within the computer network; defining policyprofiles for authorized computers and for authorized users of thecomputer network, wherein each policy profile defines rights of accessto resources within the computer network for the authorized users andthe authorized computers; upon initiation of a UDP communication foraccess to the specific resource, wherein the UDP communication isinitiated by a specific authorized user logged into a specificauthorized computer, appending the unique user identifier of thespecific authorized user and the unique system identifier of thespecific authorized computer to each UDP packet of the UCPcommunication; intercepting the UDP packets within the computer network;extracting the unique user identifier and unique system identifier fromone or more of the UDP packets of the UDP communication to identify thespecific authorized user and the specific authorized computer associatedwith the UDP communication; and allowing the UDP communication tocontinue with the specific resource as a function of the policy profileof the specific authorized user and the policy profile of the specificauthorized computer associated with the UDP communication.
 17. Themethod of claim 16, further comprising the step of blocking the UDPcommunication if one or more UDP packets does not contain a unique useridentifier or unique system identifier that matches at least one of theunique user identifiers and at least one of the unique systemidentifiers within the computer network.
 18. The method of claim 16,further comprising the step of blocking any UDP packet that does notcontain a unique user identifier or unique system identifier thatmatches at least one of the unique user identifiers and at least one ofthe unique system identifiers within the computer network.
 19. A methodfor monitoring UDP communications with a resource within a computernetwork, the computer network including a plurality of authorized usersand wherein a unique user identifier is allocated to each of theplurality of authorized users, comprising the steps of: receiving a UDPpacket at the resource within the computer network, the UDP packethaving associated therewith the unique user identifier of a specificauthorized user sending the UDP packet; obtaining the unique useridentifier from the UDP packet; and logging in a database the UDPcommunication by the specific authorized user with the resource based onthe unique user identifier obtained from the UDP packet.
 20. The methodof claim 19, wherein the unique user identifier comprises a user name ofthe specific authorized user.
 21. The method of claim 19, furthercomprising the step of decrypting the unique user identifier afterobtaining the unique user identifier from the UDP packet if the uniqueuser identifier has been previously encrypted.